プロセッサで実行中のプログラムソフトウェアをプロファイルするためのメカニズム

专利摘要:
１つ以上のプロセッサコア（１５）を有するプロセッサ（１２）は、１つ以上のプロセス（Ｐ１，Ｐ２）を含む命令を実行する実行ロジックを有する。各プロセスは１つ以上の実行スレッド（Ｔ１，Ｔ２）を含んでもよい。また、前記プロセッサは、モニタロジック（１８）とモニタプロセス（モニタコード）とを有するプロファイリングメカニズムを有する。前記モニタロジックは、前記１つ以上のプロセスをモニタし、モニタされている前記１つ以上のプロセスの制御のフローに割り込むことなく、前記１つ以上のプロセスに関連するパフォーマンスデータへのアクセスを提供する。前記モニタプロセスは、前記パフォーマンスデータを収集しうる。また、前記モニタプロセスは、ユーザモードで動作中に、前記１つ以上のプロセッサコアによって実行可能なプログラム命令を含んでもよい。
公开号:JP2011507128A
申请号:JP2010539421
申请日:2008-12-03
公开日:2011-03-03
发明作者:シェルノフ アントン
申请人:グローバルファウンドリーズ・インコーポレイテッド；
IPC主号:G06F11-34

专利说明:

[0001] 本発明はマイクロプロセッサに関し、より詳細には、プログラムの実行中にマイクロプロセッサのプロセスおよびプロセスパフォーマンスデータの収集をモニタするメカニズムに関する。]
背景技術

[0002] 長年にわたり、ソフトウェア技術者やプロセッサの設計者は、実行中にソフトウェアの挙動を測定できる機能の必要性を認めてきた。関数呼び出しの頻度や継続時間の挙動などを測定可能なプロファイリングメカニズムが数多く存在する。プロファイラまたはプログラム解析ツールは、所定のプロセスをモニタし、イベントのストリームの出力または履歴イベントのサマリーを提供する。]
[0003] 実行中のソフトウェアをプロファイルするためのさまざまな方法が存在する。例えば、１つの方法として、実行する実際のコードをインストルメント化する方法がある。一般に、「インストルメント化」とは、モニタ対象のプログラムへのモニタコードの挿入をいう。インストルメント化されたコードは、分析データを出力することができる。ほかのタイプのプロファイリングとしては、イベントベースのプロファイリング、統計プロファイリングがある。イベントベースのプロファイラのなかには、例えば、呼び出しなどのイベントをトラップするプロファイリングモジュールを使用するものがある。統計プロファイリングは、時間またはイベントの発生回数に基づく所定のインターバルでオペレーティングシステムに割り込むことによるサンプリングを使用する。]
発明が解決しようとする課題

[0004] このようなタイプの従来のプロファイラは結果を提供する。しかし、このようなプロファイラは、ＣＰＵおよび実行プロセスに追加する状態が多すぎ、プロセスフローに頻繁に割り込み過ぎるため、モニタされているプロセスを中断させる傾向がある。]
課題を解決するための手段

[0005] プロセッサで実行中のソフトウェアをプロファイリングするためのメカニズムの各種実施形態が開示される。一実施形態では、１つ以上のプロセッサコアを有するプロセッサは、１つ以上のプロセスを含む命令を実行しうる実行論理を有する。各プロセスは１つ以上の実行スレッドを含んでもよい。また、前記プロセッサは、モニタ論理とモニタプロセスとを有するプロファイリングメカニズムを有する。前記モニタ論理は、前記１つ以上のプロセスをモニタし、モニタされている前記１つ以上のプロセスの制御のフローに割り込むことなく、前記１つ以上のプロセスに関連するパフォーマンスデータへのアクセスを提供する。前記モニタプロセスは、前記パフォーマンスデータを収集しうる。]
[0006] 特定の一実施形態では、前記モニタプロセスは、ユーザモードで動作中に、前記１つ以上のプロセッサコアによって実行可能なプログラム命令を含む。]
図面の簡単な説明

[0007] マルチコア処理ノードを有するコンピュータシステムの一実施形態のブロック図。
図１のプロファイリングメカニズムの実施形態のより詳細な態様を示すブロック図。
例示的な命令のリタイアのイベントレコードを示す図。
例示的な分岐のリタイアのイベントレコードを示す図。
例示的なＤＣａｃｈｅミスのイベントレコードを示す図。
例示的なプロファイリング制御ブロックの一実施形態を示す図。] 図１
実施例

[0008] 本発明は、さまざまに変形されたり代替形態を取りうるが、その特定の実施形態が、例として図面に図示され、かつ本明細書に詳細に記載される。しかし、図面およびその詳細な説明は、開示の形態に本発明を限定することを意図するものではなく、逆に、本発明が、添付の特許請求の範囲によって規定される本発明の趣旨ならびに範囲に含まれるすべての変形例、均等物および代替例を含むことを意図することが理解されるべきである。本願にわたり、「しうる」、「してもよい」との文言は、許容を示す意味（すなわち、可能性がある、可能であること）で用いられており、義務的な意味（すなわち必須）ではない点が留意される。]
[0009] 図１を参照すると、コンピュータシステム１０の一実施形態のブロック図が示される。図に示した実施形態では、コンピュータシステム１０は、メモリ１４と、周辺機器１３Ａ〜１３Ｂとに結合された処理ノード１２を有する。ノード１２は、ノードコントローラ２０に結合されたプロセッサコア１５Ａ〜１５Ｂを有し、ノードコントローラ２０は、メモリコントローラ２２、複数のＨｙｐｅｒＴｒａｎｓｐｏｒｔ（登録商標）（ＨＴ）インタフェース回路２４Ａ〜２４Ｃ、および共有の３次（Ｌ３）キャッシュメモリ６０に接続されている。ＨＴ回路２４Ｃは周辺機器１６Ａに結合されており、周辺機器１６Ａはデイジーチェーン構成で（この実施形態では、ＨＴインタフェースを使用して）周辺機器１６Ｂに結合されている。ほかのＨＴ回路２４Ａ〜Ｂも、別のＨＴインタフェース（図示せず）を介して、ほかの同様の処理ノード（図示せず）に接続されてもよい。メモリコントローラ２２は、メモリ１４に結合されている。一実施形態では、ノード１２は、図１に示す回路を含む１つの集積回路チップでもよい。すなわち、ノード１２は、チップマルチプロセッサ（ＣＭＰ）でもよい。任意のレベルの集積化が使用されても、または別個のコンポーネントが使用されてもよい。処理ノード１２が、説明を簡略にするために省略した他の各種回路を備えてもよい点が留意される。なお、数字と文字（プロセッサコア１５Ａなど）を含む参照符号は、適切な場合、数字のみで参照することもある。] 図１
[0010] 一般に、プロセッサコア１５Ａ〜１５Ｂは、ノードコントローラ２０へのインタフェースを使用して、プロセッサコア１５Ａ〜１５Ｂ相互のほか、コンピュータシステム１０の他の構成要素（例えば周辺機器１３Ａ〜１３Ｂ、他のプロセッサコア（図示せず）、メモリコントローラ２２など）と通信しうる。このインタフェースは、好ましい方式であればどのような方式で設計されてもよい。一部の実施形態では、このインタフェース用にキャッシュコヒーレントな通信が規定されてもよい。一実施形態では、ノードコントローラ２０とプロセッサコア１５Ａ〜１５Ｂ間のインタフェースにおける通信は、ＨＴインタフェースで使用されるものと同様のパケット形式で行われうる。別の実施形態では、好適であれば、どのような通信を使用してもよい（例えばバスインタフェースでのトランザクション、異なる形式のパケットなど）。別の実施形態では、プロセッサコア１５Ａ〜１５Ｂは、ノードコントローラ２０とインタフェースを共有してもよい（例えば共有バスインタフェースなど）。一般に、プロセッサコア１５Ａ〜１５Ｂからの通信には、（メモリロケーションまたはプロセッサコアの外部のレジスタを読み出すための）リードオペレーション、（メモリロケーションまたは外部レジスタに書き込むための）ライトオペレーション、（キャッシュコヒーレントな実施形態のための）プローブへの応答、割り込みの肯定応答、およびシステム管理メッセージなどの要求が含まれうる。]
[0011] 上で説明したように、メモリ１４は、任意の適したメモリデバイスを有しうる。例えば、メモリ１４は、１つ以上のランダムアクセスメモリ（ＲＡＭ）を有し、これには、ダイナミックＲＡＭ（ＤＲＡＭ）に属するＲＡＭＢＵＳ ＤＲＡＭ（ＲＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレート（ＤＤＲ）ＳＤＲＡＭなどがある。別の実施形態では、メモリ１４が、スタティックＲＡＭなどを使用して実装されてもよい。メモリ１４は、時に取得可能な「計算機可読記憶媒体」と呼ばれることがあり、プログラムのデータと命令が記憶され、実行のために取得されうる。メモリコントローラ２２は、メモリ１４にインタフェースするための制御回路を有しうる。更に、メモリコントローラ２２は、メモリ要求をキューイングするなどのための要求キューを備えていてもよい。]
[0012] ＨＴ回路２４Ａ〜２４Ｃは、ＨＴリンクからパケットを受信し、ＨＴリンクにパケットを送信するための各種のバッファと制御回路とを備えうる。ＨＴインタフェースは、パケットを送信するための一方向リンクを有する。各ＨＴ回路２４Ａ〜２４Ｃは、２本のこのようなリンク（送信用に１本、受信用に１本）に結合されうる。あるＨＴインタフェースは、（例えば処理ノード間では）キャッシュコヒーレントな方式で動作し、（例えば周辺機器１６Ａ〜１６Ｂとの間では）非コヒーレントな方式で動作しうる。図に示した実施形態では、ＨＴ回路２４Ａ〜２４Ｂは使用されておらず、ＨＴ回路２４Ｃが非コヒーレントなリンクを介して周辺機器１６Ａ〜１６Ｂに結合されている。]
[0013] 本実施形態は、ノード間、ならびにノードと周辺機器間の通信にＨＴインタフェースを使用するが、ほかの実施形態は、このいずれかの通信に任意の所望の１つ以上のインタフェースを使用してもよい点が留意される。例えば、ほかのパケットベースのインタフェースが使用されても、バスインタフェースが使用されても、各種の標準的な周辺機器インタフェース（例えば、周辺装置相互接続（ＰＣＩ）、ＰＣＩエクスプレスなど）が使用されてもよい。]
[0014] 周辺機器１３Ａ〜１３Ｂは、どのようなタイプの周辺機器でもよい。例えば、周辺機器１３Ａ〜１３Ｂは、別のコンピュータシステムと通信するためのデバイス（例えば、ネットワークインターフェイスカード、コンピュータシステムのメイン回路基板に集積された、ネットワークインターフェイスカードと同様の回路、あるいはモデム）を有し、そのデバイスがその別のコンピュータシステムに結合されうる。また、周辺機器１３Ａ〜１３Ｂは、ビデオアクセラレータ、オーディオカード、またはドライブコントローラ、ＳＣＳＩ（Small Computer Systems Interface）アダプタ、テレフォニーカード、サウンドカード、およびＧＰＩＢインタフェースカードまたはフィールドバスインタフェースカードなどの各種のデータ収集カードを含んでいてもよい。更に、周辺機器１３Ａ〜１３Ｂは、ハードディスク、フロッピーディスクドライブ、フラッシュドライブ、光記憶媒体などの不揮発性ストレージを含んでもよい。「周辺機器」との用語は、入出力（Ｉ／Ｏ）デバイスも含むことを意図している点に注意されたい。]
[0015] 一般に、プロセッサコア１５Ａ〜１５Ｂは、所定の命令セットアーキテクチャに規定されている命令を実行するように設計された回路を有しうる。すなわち、プロセッサコア回路は、命令セットアーキテクチャに規定されている命令のフェッチ、デコード、実行、およびその結果のストアを行うように構成されうる。例えば、一実施形態では、プロセッサコア１５Ａ〜１５Ｂは、ｘ８６アーキテクチャを実装しうる。このように、プロセッサコアは、１つ以上のモードまたは保護レベルで動作してもよく、これらは、通常、「ＣＰＵ保護レベル（ＣＰＬ）」または「保護リング」と呼ばれる。ｘ８６アーキテクチャでは、ＣＰＬ０〜ＣＰＬ３の４つのレベルが存在するが、通常は２つのレベルのみが使用される。一般に使用されるレベルの一方はＣＰＬ０であり、一般に「カーネルモード」と呼ばれ、最も特権が高いレベルである。一般に使用されるもう一方のレベルはＣＰＬ３であり、一般に「ユーザモード」と呼ばれ、最も特権が低いレベルである。]
[0016] プロセッサコア１５Ａ〜１５Ｂは、スーパーパイプライン、スーパースカラーまたはその組み合わせを含む任意の所望の構成を有しうる。ほかの構成としては、スカラー、パイプライン処理、非パイプライン処理などがある。実施形態によって、アウトオブオーダーの投機的な実行が使用されても、インオーダーの実行が使用されてもよい。プロセッサコアは、上記の構造のいずれかと組み合わせて、１つ以上の命令または他の機能のためのマイクロコードを有してもよい。各種実施形態は、さまざまな他の設計的な特徴を実装してもよく、これには、キャッシュ、変換ルックアサイドバッファ（ＴＬＢ）、ミスアドレスバッファ（ＭＡＢ）、モデル固有レジスタ（ＭＳＲ）、制御レジスタ（ＣＲ）のほか、他のシステムレベルの制御ハードウェアなどが挙げられる。したがって、図に示した実施形態では、プロセッサコア１５Ａは、それぞれ、符号１６Ａ，１７Ａで示すＰＭＳＲ０，ＰＭＳＲ１と、イベントカウンタ１９Ａを備えたモニタ論理１８Ａとを有するプロファイリングハードウェアを備える。別の実施形態では、例えば、モデル固有レジスタなど、使用されるプロファイリングハードウェア要素の個数が変わってもよい点が留意される。また、イベントカウンタ１９Ａが１つのブロックとして図示されている点にも留意されたい。しかし、各種実装では、プロセッサ１５Ａが、カウント対象のイベントの近くに設けられた複数のイベントカウンタユニットを有してもよい。例えば、特定のイベントカウンタユニットが命令のリタイアをカウントする場合、カウンタユニットは、リオーダーバッファ論理（図示せず）など、このような情報を保持している論理の物理的に近くに設けられうる。図に示すように、プロセッサコア１５Ｂも同様の特徴を有する。]
[0017] 各種実施形態では、ノードコントローラ２０は、プロセッサコア１５Ａ，１５Ｂを、プロセッサコア１５Ａ，１５Ｂ同士を相互接続するか、ほかのノードに、およびメモリに相互接続するための各種の相互接続回路（図示せず）も備えうる。また、ノードコントローラ２０は、ノードの最大動作周波数と最小動作周波数、ノードの最大電源電圧と最小電源電圧などの、各種のノード特性を選択および制御するための機能も有しうる。ノードコントローラ２０は、一般に、通信種別、通信文（communication）内のアドレスなどに応じて、プロセッサコア１５Ａ〜１５Ｂと、メモリコントローラ２２と、ＨＴ回路２４Ａ〜２４Ｃとの間の通信を転送するように構成されうる。一実施形態では、ノードコントローラ２０は、受信した通信文をノードコントローラ２０が書き込むシステム要求キュー（ＳＲＱ）（図示せず）を備えうる。ノードコントローラ２０は、プロセッサコア１５Ａ〜１５Ｂ、ＨＴ回路２４Ａ〜２４Ｃ、およびメモリコントローラ２２のうちの１つ以上の宛先に転送するために、ＳＲＱにある通信をスケジュールしうる。また、図に示した実施形態では、ノードコントローラ２０は、プロファイリングハードウェアの一部をなし、このため「モニタ論理１８」と図示されている追加のモニタ論理を有する。これは、なかでも、プロセスのプロファイリング動作時に、モニタサンプルのメモリ１４と周辺機器１３とへの転送を制御するように構成されうる。]
[0018] 下で更に詳細に説明するように、プロセッサコア１５Ａ，１５Ｂは、同時に１つ以上のスレッドまたはプロセスを実行するようにそれぞれ構成されうる。また、プロセッサ１５Ａ，１５Ｂは、プロセスのプロファイリングを可能にするハードウェアとソフトウェアの機能（すなわち、プロファイリングメカニズム）をそれぞれ備えうる。例えば、プロセッサ１５Ａは、モニタプロセスをユーザモード（ＣＰＬ３）またはカーネルモード（ＣＰＬ０）で実行するように構成されうる。このモニタプロセスは、モニタされているプロセスの制御フローに割り込むことなく、プロセッサコア１５Ａまたはプロセッサコア１５Ｂで実行中のユーザモードプロセスに関連するパフォーマンスデータを収集しうる。このように、ＰＭＳＲ０，ＰＭＳＲ１、モニタ論理１８Ａ、モニタ論理１８Ｂ、およびモニタ論理１８などのプロセッサコアハードウェアにより、このようなパフォーマンスデータの収集が容易となりうる。]
[0019] また、図１に示したコンピュータシステム１０の処理ノード１２は１つであるが、別の実施形態では、実装される処理ノードの数はいくつであってもよい点が留意される。同様に、実施形態ごとに、ノード１２などの処理ノードに含まれるプロセッサコアの数はいくつでもよい。コンピュータシステム１０のさまざまな実施形態では、ノード１２当たりのＨＴインタフェースの数、ノードに結合されている周辺機器１３の数などが変わってもよい。] 図１
[0020] 図２を参照すると、図１のプロファイリングメカニズムの特定の一実施形態のより詳細な態様を例示するアーキテクチャ図が示される。より詳細には、モニタ論理１８はイベントカウンタ１９、ミスイベントカウンタ２２１を備え、一部の実装では、制御ブロックレジスタ２１８も備える。図に示すように、モニタ論理１８は周辺機器１３Ａと通信しており、周辺機器１３Ａは、図に示した実施形態では、例えば、ハードディスクドライブまたはフラッシュドライブ等の不揮発性ストレージとして図示されている。また、モニタ論理１８は、メモリ１４のほかオペレーティングシステム２５０とも通信しており、オペレーティングシステム２５０は、それぞれ、プロセッサコア１５Ａ，１５Ｂの一方または両方で実行中のオペレーティングシステム（ＯＳ）のインスタンスを表しうる。このように、一実施形態では、プロファイリングメカニズム２００は、例えばＯＳ、モニタ論理１８、ＰＭＳＲ０，ＰＭＳＲ１、メモリ１４、および周辺機器１３Ａの少なくとも一部を集合的に含んでもよい。] 図１ 図２
[0021] プロファイリングメカニズム２００は、ユーザモード（ＣＰＬ３）プロセスが、自身に関するパフォーマンスデータを極めて低いオーバーヘッドで収集できるようにするために、プロセッサアーキテクチャを拡張する。例えば、ダイナミックオプティマイザ、管理ランタイム環境などのモジュールが、現在実行中のプログラムを、高精度かつ高分解能でモニタするために有効にされ、これにより、これらのモジュールが、パフォーマンスの問題および機会を報告して、これらを直ちに修正できるようにする。アーキテクチャの拡張により、プログラムは、ポーリングを行ったり時々割り込みをかけることによって、パフォーマンスデータを収集し、このデータを検査できるようになる。この拡張によりＣＰＵにおよびプロセスに追加される状態が最小限に抑えられる。この手法は、割り込みなしで大量のデータを収集することができ、パフォーマンスフィードバックの使用のオーバーヘッドをかなり低減することができるという点で、従来のパフォーマンスカウンタとは異なる。より詳細には、一実施形態では、本明細書に記載のプロファイリングメカニズム２００は、データ収集割り込みを一切必要としないポーリング手法と併用することができる。また、プロファイリングメカニズム２００により、ユーザモードプログラムが、データ収集用のハードウェアまたはソフトウェアと対話するソフトウェアルーチンであるドライバを呼び出すことなく、自身のデータ収集を制御できるようになる。最後に、プロファイリングメカニズム２００は、スレッドのコンテキスト内で実行され、このため、システム内の複数のプロセスがプロファイリングメカニズム２００を同時に使用することができる。]
[0022] 各種実施形態では、モニタ論理１８は、有効に設定されると、ユーザモードコードの実行中かつ所定のインターバルで１つ以上のイベントをモニタおよびカウントして、メモリ１４内の実行中のプロセスのアドレス空間において、リングバッファ（例えば、リングバッファ２３１Ａ）にイベントレコードを挿入するように構成されうる。リングバッファがユーザ指定のしきい値まで一杯になると、モニタ論理１８は、ＯＳに割り込みを発生させ、ＯＳは、この割り込みを使用して、バッファの内容を不揮発性ストレージ（例えば、周辺機器１３Ａ）に移動させるか、バッファの内容を別様に使用することにより、バッファを空にするようにプロセスに指示しうる。適切なＯＳのサポートにより、割り込みが、別個のプロセスまたはスレッドに供給される場合もある。一部の実施形態では、プロファイリングメカニズム２００は、ユーザプログラムがリングバッファ内のイベントレコードに情報を手動で挿入できるようにもしており、ユーザプログラムが、バッファ内の他のデータの解釈に影響を及ぼしうるソフトウェアイベントを記録できるようになる。]
[0023] 一実施形態では、プロファイリングメカニズム２００は、命令のリタイア、分岐（例えば制御の移動）のリタイア、および特定のデータキャッシュミスなどのイベントに関連する情報を収集しうる。しかし、別の実施形態では、ＣＰＵサイクル、データＴＬＢミス、命令ＴＬＢミス、浮動小数点演算、命令キャッシュ（ＩＣａｃｈｅ）ミス、およびメモリロック競合などの他のイベントがモニタされてもよいことも考察される。イベント情報はイベントレコードに記録され、この例が図３Ａ〜図３Ｃに示される。] 図３Ａ 図３Ｂ 図３Ｃ
[0024] 各種実施形態では、ＯＳと相互動作し、協動するために、ＯＳは、プロファイリングメカニズム２００が利用可能かどうかを検出し、利用可能な場合、存在するプロファイリング機能を特定するように構成さうる。ＯＳが、プログラムがプロファイリングメカニズム２００と対話するのを許可する場合には、ＯＳはプロファイリングメカニズム２００を有効に設定しなければならない。ＯＳは、プロファイリングメカニズム２００を有効にすることによって、プロファイリング状態のコンテキスト切替をコミットする。ＯＳは、プロファイリング割り込みを有効にすることによって、これらの処理をコミットする。また、ＯＳの動作に関するデータが、どのユーザプロセスにもリークされることはなく、あるユーザプロセスの動作に関するデータが他のプロセスにリークされることはない。]
[0025] 図に示した実施形態では、メモリ１４は、複数のプロセスおよびスレッドと、プロファイリング制御ブロック情報２７５とのための記憶域を含む。より詳細には、メモリ１４は、プロセスおよびスレッドのために割り当てられる４つの例示的なアドレス空間を有して図示されている。左から参照すると、プロセスおよびスレッド（Ｐ１Ｔ１）には、何らかのアプリケーションコードおよびモニタコードを含むユーザモードコードが含まれるほか、このアドレス空間には、イベントレコードを記憶するためのリングバッファ２３１Ａも含まれる。また、モニタコードは、リングバッファ２３１Ａをモニタするポーリングコードを含んでもよく、上で説明したように、リングバッファ２３１Ａが所定のしきい値まで一杯になったときにモニタ論理１８によって通知されうる。次のアドレス空間は、Ｐ１Ｔ２であり、モニタコードを含むユーザモードコードとリングバッファ２３１Ｂとが含まれるという点で、Ｐ１Ｔ１と同様である。同様に、次のアドレス空間はＰ２Ｔ１であり、第２のプロセスおよびスレッドと呼ぶ。]
[0026] メモリ１４内の第４のアドレス空間は、Ｐ１Ｔ３で示すモニタスレッドの実施形態を示す。このモニタスレッドのアドレス空間には、この複数のリングバッファ（例えば、２３２Ａ，２３２Ｂ）のための空間が含まれる。図に示すように、モニタコードはユーザモードコードである。モニタスレッドＰ１Ｔ３は、任意のプロセッサコアで実行中の複数のプロセスをモニタするために使用されうる。図に示した実施形態では、２つのリングバッファが存在しており、このため、２つのプロセスがモニタされている。しかし、別の実施形態では、いくつのスレッドまたはプロセスがモニタされてもよい。例えば、モニタスレッドＰ１Ｔ３が他のプロセスのスレッドをモニタしている場合、リングバッファ２３２Ａと２３２Ｂが、モニタ中のプロセスと共有されているメモリ内に存在し、これらのバッファが、モニタスレッドＰ１Ｔ３と、モニタ対象のスレッドの両者によって読み書きされうる。]
[0027] イベントのモニタ中に、一実施形態では、命令が、ユーザモード（例えば、ＣＰＬ３）で実行しており、例えば、命令をカウントするためのアドバンスト・マイクロ・デバイセズ規格などの命令カウント規格に従って、そのモードにおいて命令カウントに寄与する場合、その命令がカウントされうる。しかし、別の実施形態では、命令を他の方法でカウントしてもよい。更に、システム管理モード（ＳＭＭ）中（あるいは、このモードに入るか、ここから出た場合）はプロファイリングが無効なことがある。]
[0028] プロファイリングが有効に設定される（下で詳細に記載する）と、ユーザスレッドは、新しい命令により、その動作に完全に制御を所有することができる。一実施形態では、この新しい命令は、ＬＬＷＰＣＢ、ＳＬＷＰＣＢおよびＬＷＰＩＮＳと呼ばれうる。これらの命令は、プロファイリング制御ブロック２７５（図４に更に詳細に図示する）へのポインタを指定し、内部プロファイリング状態を初期化し、プロファイリング動作を開始（または終了）して、リングバッファにイベントレコードを挿入する。マルチスレッドプロセス内の各スレッドは、別個にプロファイリング動作を構成しうる。スレッドは、自身のリングバッファとイベントカウンタとを有し、これらは、残りのスレッド状態とコンテキスト切替されうる。しかし、図２のスレッドＰ１Ｔ３などの１つのモニタスレッドが、所定のプロセスにおいて複数の他のスレッドからのデータを処理できるように、リングバッファが共有されうる。] 図２ 図４
[0029] プロファイリング動作中に、モニタ論理１８は、１つ以上のタイプのイベントをモニタおよび報告するように構成されうる。一実施形態では、モニタ論理１８は、イベントをカウントし、イベントレコードを収集し、メモリのバッファ（例えば、リングバッファ２３１，２３２）にイベントレコードを記憶し、バッファが一杯になったことを報告し、イベントレコードを記憶する時に特定のイベントカウンタをリセットし、リングバッファ内の情報を不揮発性ストレージに転送するのを制御するように構成された機能を有しうる。これらの機能については、下で更に詳細に説明する。]
[0030] 一実施形態では、命令がリタイアされるたびに、モニタ論理１８は、命令に関連するすべてのイベントの内部イベントカウンタ１９をデクリメントする。命令は０、１、または複数のイベントを発生させることもあれば、イベントを発生させないものもある。例えば、メモリのポインタを介する間接的な分岐は、命令のリタイア、分岐のリタイアとしてカウントされ、最大２つ（またはＴＬＢミスがある場合は２を超える）のデータキャッシュ（ＤＣａｃｈｅ）ミスと最大２つの命令キャッシュ（ＩＣａｃｈｅ）ミスを発生させうる。また、一部のイベントは、そのイベントのカウントを調整しうるフィルタまたは条件を有しうる。例えば、キャッシュミスイベントは、レーテンシが所定の最小値を超えるイベントのみをカウント対象とするように指定する。]
[0031] また、イベントカウンタがゼロに達したときも、イベントを報告しなければならない。したがって、モニタ論理１８は、イベントレコード（図３Ａに示す）を収集する。より詳細には、一実装では、レコードイベントの内部コピーに書き込まれうる。命令のリタイアなどの大半のイベントの場合、モニタ論理１８は、カウンタがゼロになる原因となった命令についてのイベントレコードを収集するように構成されうる。しかし、後で更に詳細に説明するように、モニタ論理１８は、イベントを発生させた次の命令のイベントレコードデータを収集するか、あるいはレコードをキャプチャするために他の動作を行うように構成されてもよい。] 図３Ａ
[0032] モニタ論理１８は、特定の実装に応じて、一度に（すなわち同時に）、１つまたは複数のイベントに関するイベント情報を収集しうる。一実装では、モニタ論理１８は、対象となる（eligible）イベントの１つを選択し、選択されたイベントレコードがメモリ１４に書き込まれるまで、他の期限切れのイベントが待機して、その後、モニタ論理１８は、待機イベントのための次の対象となる（eligible）命令を選択しうる。別の実装では、複数のイベントカウンタがゼロになると、モニタ論理１８はイベントごとに１つのイベントレコードを収集して、これらをメモリ１４に逐次的に書き込んでもよい。]
[0033] モニタ論理１８は、特定の場合に、イベント発生を廃棄するように構成されうる。例えば、所定のリングバッファをディスクからページインする必要がある場合、未処理のイベントレコードデータを維持する理由がなくなる。イベントが廃棄されると、モニタ論理１８は、イベントを発生させる次の命令のイベントレコードを収集しうる。同様に、モニタ論理１８が、完全なイベントレコードを収集するために命令を再実行する必要がある場合、リタイアの代わりに、再生が何かの理由で中止されうる。この場合、イベントカウンタ１９はゼロのままとなり、モニタ論理１８は、イベントを発生させる次の命令のイベントレコードを収集しうる。]
[0034] イベントカウンタがゼロに達した場合など、完全なイベントレコードが収集されると、モニタ論理１８は、プロセスのアドレス空間のリングバッファ（例えば２３１）にイベントを記憶して、リングバッファポインタを先に進めるように構成されうる。この時点でリングバッファが一杯の場合、モニタ論理１８はミスイベントのミスイベントカウンタをインクリメントし、リングバッファポインタを先に進めない。]
[0035] 複数のイベントレコードが同時に記憶できる状態にある場合、一実装では、１つのイベントのみが記憶されうる。モニタ論理１８は、他のイベントレコードの記憶を遅らせるか、あるいは、情報を廃棄して、必要に応じて、廃棄されたイベントタイプについて次の対象となる（eligible）命令を再び選択してもよい。ストアが命令のリタイアと同期して完了する必要がない点が留意される。換言すれば、プロファイリングメカニズム２００がイベントレコードの内容をバッファする場合、イベントを発生させた命令がリタイアされたあとに、数サイクルしてからストア段階（および後続の段階）が完了してもよい。イベントおよび命令に関連するデータは厳密であるが、プロファイリングプロセスの残りが後から完了してもよい。]
[0036] プロファイリングのしきい値割り込みが有効にされ、リングバッファ内の使用中の空間がユーザ定義の所定のしきい値を超えた場合、モニタ論理１８は、何らかのプロセスに対してバッファを空にするようにＯＳが指示できるように、割り込みを開始するように構成されうる。この割り込みは、例えば、上記の例で説明したＰ１Ｔ３などのモニタ中のプロセスまたは別個のプロセスまたはスレッドに送られうる。割り込みは、しきい値を到達させたイベントよりもかなり遅れて発生することがある点が留意される。]
[0037] イベントレコードが記憶されると、記憶されているイベントのカウンタが、そのプログラムされたインターバル（任意の乱数化が適用される）にリセットされ、そのイベントのカウントが再開されうる。イベントレコードが記憶された場合、またはミスイベントカウンタがインクリメントされた場合にリセットが行われる。]
[0038] 一実施形態では、リングバッファのイベントを処理するための割り込みが発生するまで、ユーザプロセスは待機しうる。しかし、これには、何らかのカーネルまたはドライバのサポートが必要となりうる。このように、割り込みは、カーネルモードルーチンが許可する場合にのみ有効にされうる。例えば、ユーザプログラムは、ドライバを呼び出して、プロファイリングメカニズムの割り込みをセマフォまたはミューテックスと関連付けてもよい。割り込みが発生した場合、ドライバは関連するオブジェクトに通知しうる。オブジェクトで待機している任意のスレッドが起動されて、バッファを処理しうる。しかし、他のドライバモデルも可能であると考察される。]
[0039] 別の実施形態では、ユーザプロセスは、定期的にリングバッファ（例えば２３１）をポーリング（例えば２３３）して、このリングバッファからイベントレコードを除去し、ハードウェアプロファイリングメカニズム２００がレコードを記憶し続けることができるように、テイルポインタを先に進めるスレッドを有しうる。]
[0040] 前述のように、モニタされたイベントが、そのイベントカウンタをオーバーフローさせると、モニタ論理１８は、イベントレコードを適切なイベントリングバッファに書き込む。各種実施形態では、図３Ａ〜図３Ｃに示すように、リングバッファの各イベントレコードは３２バイト長である。しかし、別の実施形態では、必要に応じてほかのバイト数が使用されてもよいと考察される。実際のレコードサイズは、ＣＰＵＩＤコマンドを使用して、プロファイリングメカニズム２００を特徴付けることで決定することができる。プロファイリングメカニズム２００がイベントレコードを書き込む際に、イベントレコードの「予約済み」フィールドがゼロにセットされうる点が留意される。しかし、別の実施形態では、プロファイリングメカニズムを特徴付ける他の方法を提供してもよい。図３Ａ〜図３Ｃに示すイベントレコードは例示的なレコードであることに注意されたい。別の実施形態では、イベントレコードが、ほかのフィールドを有しても、レコード内でのフィールドの並び方が異なっても、フィールドが図３Ａ〜図３Ｃに示すイベントレコードとは異なるサイズを有してもよい。] 図３Ａ 図３Ｂ 図３Ｃ
[0041] 図３Ａを参照すると、命令のリタイアの例示的なイベントレコード３０５が示される。最初の行を右からみていくと、バイト０は、イベントレコードタイプを指定するイベントＩＤフィールドである。イベントＩＤが「１」の場合、命令のリタイアのイベントレコードを表す。一実施形態では、有効な識別子は１〜２５５であり、ゼロは無効なイベント識別子である。次のバイトはコア識別子フィールドである。マルチコアシステムの場合、このフィールドは、プロファイリングメカニズム２００が実行中のコアを識別する。このフィールドにより、ソフトウェアが、ＣＰＵ情報を残したまま、複数のスレッドからのイベントレコードを１つのバッファにまとめることが可能となる。一実施形態では、シングルコアシステムでは、ＩＤにゼロが使用されうる。一部の実施形態では、コア識別子は、マシン固有レジスタ（ＭＳＲ）、あるいはオペレーティングシステムまたは他のコードによって初期化される他の値から与えられうる。次の２バイトは、イベント固有のフラグフィールドであり、イベントレコードのタイプに応じて任意の数のフラグを含んでもよい。この例示的なイベントレコードでは、フィールド全体が予約されている。次の４バイトは、イベント固有のデータフィールドを表す。この例示的なイベントレコードでは、これらのバイトは予約されている。次の行は、バイト８：１５を含み、命令アドレスを表す。] 図３Ａ
[0042] 一実施形態では、命令がリタイアされるたびに、イベントカウンタがデクリメントされる。カウンタがゼロになると、プロファイリングメカニズム２００内のモニタ論理１８は、イベント識別子に「１」を指定してイベントレコードを記憶するように構成されうる。イベントレコードのバイト８：１５は、その実行がイベントを発生させた命令の線形命令ポインタアドレスを含む。]
[0043] 図３Ｂを参照すると、分岐のリタイアの例示的なイベントレコード３１０が示される。イベントレコード３１０の構造は、図３Ａに示したイベントレコード３０５と同様である。しかし、図３Ｂに示すように、イベントＩＤは２であり、このイベントレコードが分岐のリタイアのイベントレコードであることを示す。イベント固有フラグフィールドには、ビット位置３１：２９に３つのフラグが含まれる。このフラグは、それぞれ、ＴＫＮ、ＰＲＤおよびＰＲＶである。一実施形態では、ＴＫＮビットは、分岐を辿った場合は論理１を示し、分岐を辿らなかった場合は論理０を示す。ＰＲＤビットは、分岐が正しく予測された場合は論理１を示し、予測ミスの場合は論理０を示す。ＰＲＶビットは、ＰＲＤビットが有効な場合は論理１を示し、予測情報が無効な場合は論理０を示す。図３Ａと同様に、図３Ｂのバイト８：１５は命令アドレスを含むほか、バイト１６：２３は、分岐後の命令のアドレスを表す。このアドレスは、分岐を辿った場合は分岐先のアドレス、分岐を辿らなかった場合は直進（fall-through）のアドレスである。] 図３Ａ 図３Ｂ
[0044] 各種実施形態では、分岐を辿ったかどうかを問わず、制御の遷移がリタイアされるたびに、イベントカウンタがデクリメントされる。制御の遷移には、ショート分岐、ロング分岐（ＪＣＸＺおよびその変種を含む）、ＬＯＯＰｘ、ＣＡＬＬ、およびＲＥＴの各命令が含まれる。しかし、同期、非同期を問わず、トラップまたは割り込みは含まれず、ＣＰＬ３、ＳＭＭまたはＳＶＭとの間の切り替えオペレーション（例えばＳＹＳＣＡＬＬ、ＳＹＳＥＮＴＥＲまたはＩＮＴ ３）は含まれなくてもよい。]
[0045] カウンタがゼロになると、プロファイリングメカニズム２００内のモニタ論理１８は、イベント識別子が「２」のイベントレコードを記憶するように構成されうる。フラグは、分岐を辿ったかどうか（無条件遷移の場合は常に真）と、正しく予測されたかどうか（直接分岐の場合は常に真）を示す。また、レコードは、分岐命令と分岐先のアドレスも含む。条件付き分岐を辿らなかった場合、分岐先は直進（fall-through）のアドレスとなる。プロファイリングメカニズム２００の一部の実装では、分岐の一部または全てに関する分岐予測情報をキャプチャしないこともある。イベントレコード内のビットが、予測情報が有効かどうかを示しうる。]
[0046] 図３Ｃを参照すると、ＤＣａｃｈｅミスの例示的なイベントレコード３２０が示される。イベントレコード３２０の構造は、図３Ａ，３Ｂにそれぞれ示したイベントレコード３０５，３１０と同様である。しかし、図３Ｃに示すように、イベントＩＤは３であり、このイベントレコードがＤＣａｃｈｅミスのイベントレコードであることを示す。イベント固有フラグフィールドには、ビット位置３１：２８に２つのフラグが含まれる。このフラグは、それぞれ、ビット位置３１：２８を含むＳＲＣとＤＡＶであり、一実施形態では、ＳＲＣビットは、要求されたデータのソースのビットコードを表す。ＳＲＣコードのセットの例を表１に示すが、他のコードも可能であり、考察される。ＤＡＶビットは、データアドレスが有効な場合は論理１を示し、データアドレスが無効な場合は論理０を示す。図３Ａと同様に、図３Ｃのバイト８：１５にも命令アドレスが含まれる。また、バイト１６：２３は、メモリ参照（ＤＡＶビット＝１の場合）のアドレスを表す。下で更に詳細に説明するように、イベント固有データバイトは「レーテンシ」に指定され、（サイクルにおける）キャッシュミスの総レーテンシを示す。] 図３Ａ 図３Ｃ
[0047] 各種実施形態では、ＤＣａｃｈｅミスのレーテンシが所定のＬａｔｅｎｃｙしきい値を超える場合、および／または、データがキャッシュまたはメモリ階層の、カウントするように選択されたレベルから提供される場合、メモリからのロードがＤＣａｃｈｅミスを発生させるたびに、イベントカウンタがデクリメントされる。一実施形態では、１回のロードで２つのミスを発生させる不整合アクセスにより、イベントカウンタが１だけデクリメントされ、イベントを報告する場合、データが、ミスとなった最下位アドレスとなる。プロファイリングメカニズム２００は、ＴＬＢウォーク、ローカルまたはグローバルディスクリプタテーブル（ＬＤＴ、ＧＤＴ）の参照、ＴＬＢミスなどに間接的に起因するキャッシュミスはカウントしなくてもよい。したがって、一実施形態では、プロファイリングメカニズム２００は、命令が直接の原因となったロードのみをカウントしうる。]
[0048] カウンタがゼロになると、モニタ論理１８は、イベント識別子が「３」のイベントレコードを記憶するように構成されうる。フラグは任意選択でデータのソースを示す（利用可能な場合）。イベントレコードには、総レーテンシ、ロード命令のアドレス、および参照されたデータのアドレスが含まれる。しかし、プロファイリングハードウェア自体によって発生したキャッシュミスはカウント対象とならない。]
[0049] ｘ８６アーキテクチャでは、複数のロードが同時に未処理となりうる点が留意される。しかし、場合によっては、キャッシュミスの解決を待機中のすべてのロードに対して、完全なレーテンシカウンタを設定することは実際的ではないこともある。このような場合、さまざまな単純化が使用されてもよいと考えられる。]
[0050] 例えば、一実装では、レーテンシが２ｊの倍数に丸められうる（ｊは、１〜４（１と４を含む））。例えば、以降の説明において、ｊ＝４、２ｊ＝１６と仮定する。イベントレコード中で報告されるレーテンシの下位４ビットが０となる。実際のレーテンシカウンタは、（１６の待機サイクルごとに）１６ずつインクリメントされうる。プロファイリングメカニズムの機能の問合せ時に、ＣＰＵＩＤ命令によって、ｊの値が、「ＰＬａｔｅｎｃｙＲｎｄ」あるいは同様の名前で戻される。しかし、ｊの値を戻すために他のメカニズムを使用することもできる。]
[0051] 別の実装では、レーテンシのカウントの開始時に、近似が実行されてもよい。１６の増分でカウントする場合、ロードが待機を開始したときに、１６サイクル開始する必要がない。この代わりに、最初の１６サイクルの待機中の任意の時点で、レーテンシ値が、０から１６に一気に上がりうる。]
[0052] 別の実装では、総レーテンシの上限が、２ｎ−１６（ｎ≧１０）に制限されうる。このため、レーテンシカウンタは、最大値に達するとカウントを中止する飽和カウンタを実装する。例えば、ｎ＝１０の場合、レーテンシ値は１６きざみで０〜１００８の範囲を取り、１００８で止まる。また、ｎ＝１０の場合、各カウンタを、わずか６ビットを使用して実装することができる。ｎの値は、プロファイリングメカニズムの機能の問合せ時に、ＣＰＵＩＤ命令（または別のメカニズム）によってＰＬａｔｅｎｃｙＭａｘとして戻される。]
[0053] 上記の例では、キャッシュミスイベントをカウント対象とすべきかどうかを決定する比較を実行する際に、イベントをフィルタするために使用されるレーテンシしきい値が１６の倍数である点が留意される。上記の単純化を使用すべきかどうか決定する場合、チップ面積（area）と電力に関して実際的な単純化を選択すべきである点にも留意されたい。]
[0054] 前述のように、ＤＣａｃｈｅミスのイベントレコードは、データの線形アドレスを報告する。線形アドレスの記録方法は、報告されるイベント自体と、キャッシュミスイベントの報告に要する時間とに影響する。したがって、モニタ論理１８は、カウンタをゼロにするイベントか、あるいは次の対象となる（eligible）イベントのいずれかのデータをキャプチャしうる。
プロファイリングの設定]
[0055] 動作時に、一実施形態では、プロファイリングメカニズム２００が存在するかどうかを識別するためにＣＰＵＩＤ命令が使用されうる。さらに詳しくは、Ｃａｌｌ：ＣＰＵＩＤ≦ＥＡＸ：８０００＿０００１を実行すると、プロセッサＥＤＸビット０が戻されうる。ビット０が論理値１にアサートされている場合、プロファイリングメカニズム２００が存在し、ビット０が論理値０にアサートされている場合、プロファイリングメカニズム２００が存在しない。しかし、別の実施形態では、これらの論理値と、論理値に対応する機能とが逆転してもよいと考えられる。]
[0056] また、サポートされているプロファイリングメカニズムの機能を識別するために、ＣＰＵＩＤ命令が、新しいリーフ要求コードと共に使用されうる。例えば、Ｃａｌｌ：ＣＰＵＩＤ≦ＥＡＸ：８０００＿００１Ｃ（拡張機能ではＥＡＸ：８０００＿００１Ｄを使用）を実行すると、特定の値が戻されうる。この値のセットの例を下の表２に示すが、他の値およびビット機能も可能であり、考察される。]
[0057] 一実施形態では、ＥＡＸ内に戻されるビットは、ＰＭＳＲ０から取得され、プロファイリングメカニズム２００の現在有効な機能を示している。しかし、これらは、現在のプロセッサにおいてプロファイリングメカニズム２００のすべての機能を示すＥＤＸ内に戻されるビットのサブセットである。プロファイリングメカニズム２００の使用可能な全機能をサポートするようにＯＳが構成されていない場合には、ＯＳは、プロファイリングメカニズム２００のサブセットを有効に設定しうる。例えば、ＯＳがプロファイリングしきい値割り込みを処理しないように構成されている場合、この機能を無効にしうる。ユーザモードのソフトウェアは、使用できる機能を記述するＥＡＸのビットを解釈するように構成する必要がある。オペレーティングシステムは、プロファイリングメカニズム２００の機能を決定し、使用可能な機能のすべてまたは一部を有効にするために、ＥＤＸのビットを使用するように構成される必要がある。別の実施形態では、特に、ここに記載した例を拡張した実装や、ここに記載した例のサブセットの実装では、プロファイリングメカニズムが、異なる命令またはメカニズムを使用してプロセッサの構成を報告し、追加のデータおよびパラメータを報告してもよい点に留意されたい。]
[0058] ＜プロファイリングの有効化と制御＞
前述のように、ＰＭＳＲはモデル固有レジスタであり、プロファイリングメカニズム２００のハードウェアを記述し、これを制御している。一実施形態では、ＣＰＵＩＤ ８０００＿０００１のＥＤＸビット０が論理値１にセットされている場合、ＰＭＳＲが利用可能である。]
[0059] ＰＭＳＲ０は、プロファイリングメカニズム２００機能の有効レジスタと呼ばれうる。このように、ＰＭＳＲ０は、プロファイリングメカニズム２００が、所定のプロセッサでどのように使用できるかを制御しうる。どのビットが、どのような値にアサートされているかに応じて、プロファイリングメカニズム２００の使用を禁止したり、その動作を数通りの方法で制限することができる。ＰＭＳＲ０で有効にできる機能を下記の表３に示す。しかし、表３に示すＰＭＳＲ０の機能は例示であり、別の実施形態では、他の機能やビットが使用されてもよいと考えられる点が留意される。]
[0060] ＯＳは、起動時（または、プロファイリングメカニズム２００ドライバのロード時）に、プロファイリングメカニズム２００のサポートレベルを示すＰＭＳＲ０をロードするように構成されうる。一実装では、プロファイリングメカニズム２００の列挙時に、ＣＰＵＩＤ命令に応答してＥＤＸにセットされるビットのみを、ＰＭＳＲ０中でオンにすることができる。その他のビットをセットしようとすると、＃ＧＰフォルトが発生しうる。ユーザコードは、ＥＡＸ＝８０００＿００１Ｃを使用してＣＰＵＩＤを実行することでＰＭＳＲ０の内容を調べ、ＥＡＸの内容を調べることができる。]
[0061] 図１の説明と併せて上で説明したように、ＰＭＳＲ１は、プロファイリング制御ブロック（ＰＣＢ）ポインタの内部コピーへのアクセスを提供する。一実施形態では、下で更に詳細に説明するように、カーネルモード時には、このレジスタにＲＤＭＳＲ命令を実行すると、ＳＬＷＰＣＢ命令に対応するオペレーションが実行され、このレジスタにＷＲＭＳＲ命令を実行すると、ＬＬＷＰＣＢ命令に対応するオペレーションが実行される。] 図１
[0062] 図１の説明と併せて、ＰＭＳＲ２は、モニタ対象のスレッドが実行中のプロセッサを識別するために、イベントレコードのコアＩＤフィールドに記憶されている値を提供しうる。この値は、ＢＩＯＳまたはオペレーティングシステムによってセットされるか、あるいは、ハードウェアによって初期化されうる。] 図１
[0063] 一実施形態では、ユーザモードにおいて、プロファイリングを有効／無効にし、プロファイルされているイベントを制御するために、ＬＬＷＰＣＢ命令が使用されうる。同様に、ユーザモードにおいてプロファイリングの現在の状態を問合せるために、ＳＬＷＰＣＢ命令が使用されうる。これらの命令は、ＰＭＳＲ１内のＰＣＢポインタへのユーザモードのアクセスを事実上提供する。また、ＬＷＰＩＮＳ命令は、イベントリングバッファにイベントレコードをソフトウェアによって挿入可能にする。
ＬＬＷＰＣＢ命令]
[0064] 一実施形態では、ＬＬＷＰＣＢ命令は、Load Lightweight Profiling Control Block（ロード軽量プロファイリング制御ブロック）の略字であり、ＤＳ：ｒＡＸにおいてプロファイリング制御ブロック（ＰＣＢ）から、プロファイリングメカニズム２００のハードウェアの状態をセットし、指定されている場合、プロファイリングを有効に設定しうる。ｒＡＸレジスタ内のＰＣＢアドレスの以前の値を戻しうる。]
[0065] 一実施形態では、プロファイリングを無効にするには、ｒＡＸ＝０を指定してＬＬＷＰＣＢ命令が実行されうる。このオペレーションは、マシンが保護モードにある場合にのみ発行されるが、任意の特権レベルで実行できる。しかし、ＣＰＬ３以外の特権レベルから実行された場合、内部ＰＣＢポインタはロードされるが、プロセッサがＣＰＬ３に入るまで、プロファイリングメカニズム２００の状態の残りの初期化が遅延されうる。これにより、ＰＣＢを、直ちにページインが必要なメモリに配置でき、ページフォルトがリング３から発生する。]
[0066] 一実施形態では、プロファイリングは、ユーザプログラムによってのみオンにしなければならないことがある。暗黙的にプロファイリングメカニズム２００をオンにするＣＰＬ３への遷移は、拡張コンテキスト保存／復元メカニズムを使用して行わなければならず、このメカニズムは、プロファイリングメカニズム２００の揮発性の状態の一部を復元し、プロファイリングメカニズム２００が、自身の状態の残りをＰＣＢから初期化する必要がある。]
[0067] プロファイリングメカニズム２００は、現在アクティブな場合、内部状態を、古いＰＣＢ内のメモリにフラッシュする。次に、プロファイリングメカニズム２００は、新しいＰＣＢから新しい内部状態を設定して、得られたプロファイリングメカニズム２００の状態を示すように、新しいＰＣＢ．Ｆｌａｇｓフィールドに書き込むように構成されうる。下で更に詳細に説明するように、ＰＣＢ．Ｆｌａｇｓフィールドは、実際にプロファイルされているイベントと、しきい値割り込みが有効にされているかを示すビットを格納する。
ＳＬＷＰＣＢ命令]
[0068] 一実施形態では、ＳＬＷＰＣＢ命令は、Store Lightweight Profiling Control Block（ストア軽量プロファイリング制御ブロック）の略字であり、実行すると、プロファイリングメカニズム２００の現在の状態をメモリ内のＰＣＢにフラッシュし、ｒＡＸにＰＣＢの現在のアドレスを戻す。プロファイリングメカニズム２００が現在アクティブでない場合、ＳＬＷＰＣＢ命令を実行すると、ｒＡＸがゼロにセットされうる。このオペレーションは、マシンが保護モードにある場合にのみ発行されるが、任意の特権レベルで実行できる。]
[0069] ＜ＬＷＰＩＮＳ命令＞
一実施形態では、ＬＷＰＩＮＳ命令は、実行されると、ハードウェアがリングバッファにレコードを挿入するのと同様に、現在実行中のスレッドのイベントリングバッファにイベントレコードを挿入し、リングバッファポインタを先に進める。挿入されたレコードのイベントＩＤは、ユーザが挿入したイベントであることを示す所定の値（例えば２５５）となり、レコードの他のフィールドは、この命令の実行時にプロセッサの汎用レジスタから取得されうる。ＬＷＰＩＮＳ命令は、成功を示すためにプロセッサキャリービット（または他の任意のフラグビット）をクリアするか、または、リングバッファが一杯であることを示すために、このビットをセットしうる。]
[0070] 図４の説明に関連して、更に詳細に説明するように、ＰＣＢは、プロファイリングメカニズム２００の動作の詳細を指定し、一実施形態では、ＰＣＢは複数のフィールドを含み、メモリのインタラクティブな領域に記憶される。この領域では、一部のフィールドが、プロファイリングメカニズム２００のハードウェアによって制御および変更され、他のフィールドは、プロファイリングメカニズム２００のイベントレコードを処理するソフトウェアによって制御および変更される。図２に示すように、モニタ論理１８は、高速化のために、ＰＣＢからの情報の一部を内部レジスタ（例えば、制御ブロックレジスタ２１８）にキャッシュするように構成されている。] 図２ 図４
[0071] 図４を参照すると、例示的なプロファイリング制御ブロック４７５が示される。図に示した実施形態では、ＰＣＢ４７５に含まれるバイト数は、例えば、モニタされているイベントの個数に応じて、可変であり動的である。したがって、図４においては、ＰＣＢ４７５は、Ｍ＋８バイトで示される。また、ＰＣＢ４７５は、複数のフィールドも有する。ＰＣＢ４７５のフィールドを、表４と共に下で更に詳細に説明する。表４の「Ｒ／Ｗ」列は、プロファイリングメカニズム２００が有効に設定されている間に、フィールドがどのように変更されるかを示す。「モニタ論理」は、モニタ論理１８がフィールドを変更することを表し、「Ｉｎｉｔ」は、モニタ論理１８がＬＬＷＰＣＢ命令を実行中にフィールドを変更することを表し、「ＳＷ」は、ソフトウェアが変更しうることを表し、「Ｎｏ」は、ＰＣＢが使用中である限り、フィールドの変更が禁止されていることを表す。別の実施形態では、プロファイリング制御ブロックは、図４と表４に示され、本明細書に記載するプロファイリング制御ブロックに対し、追加の機能または異なる機能を有する他のフィールドを含んでもよい点が留意される。] 図４
[0072] 図４に示す実施形態では、フラグフィールドは、ビット位置０〜３，３１の５つのフラグを含む。フラグは、それぞれ、ＥＮ、ＩＲＥ、ＢＲＥ、ＤＭＥおよびＩＮＴである。ＥＮフラグは、プロファイリングが有効に設定されているかどうかを示す。ＩＲＥフラグは、命令のリタイアのイベントが有効に設定されているか示し、ＢＲＥフラグは、分岐のリタイアのイベントが有効に設定されているか示し、ＤＭＥフラグは、ＤＣａｃｈｅミスイベントが有効に設定されているか示し、ＩＮＴフラグは、しきい値割り込みが有効に設定されているか示す。別の実施形態は、追加のイベントをモニタしてもよく、追加のフラグビットを含んでもよい。] 図４
[0073] ＰＣＢのフィールド内の大部分は、プロファイリングセッションの間（プロファイリングメカニズム２００を有効に設定してから無効にするまでの時間）、固定されうる。つまり、フィールドが、プロファイリングメカニズム２００のハードウェアが有効にされたときにロードされ、必要に応じて同じ位置から定期的に再ロードされうる。定数のフィールドの内容はプロファイリングの実行中は変更を禁止されており、変更された場合には結果が予測不可能となる。また、ＰＣＢメモリを、リードオンリーに変更したりアンマップすると、モニタ論理１８が次にＰＣＢメモリへのアクセスを試みたときに、例外が発生することがある。]
[0074] フィールドのいくつかは、イベントレコードバッファを空にしているソフトウェアに進捗を通知するために、モニタ論理１８によって変更されうる。プロファイリングメカニズム２００が有効に設定されている間は、ソフトウェアは、このようなフィールドを読み出すことができるが、変更は禁止されている。他のフィールドを使用して、ソフトウェアがリングバッファを空にしたことを通知できるようにしてもよい。ソフトウェアがこのようなフィールドに書き込み、モニタ論理１８が必要に応じてこのフィールドを読み出しうる。効率のために、上で述べたように、プロファイリングが有効な場合に、ＰＣＢのフィールドの一部が制御ブロックレジスタ２１８に複製されうる（shadowed）。モニタ論理１８は、必要に応じて、下で更に詳しく説明するように、ソフトウェアが先に進めるように、これらのフィールドをメモリからリフレッシュ（またはメモリにフラッシュ）してもよい。]
[0075] 前述のように、ＰＣＢフィールドのいくつかは、モニタ論理１８とユーザソフトウェアとによって非同期で書き込まれうる。関連するメモリトラフィックを低減させるために、いくつかの技術を使用することができる。例えば、モニタ論理１８が、バッファのヘッドポインタとテイルポインタの内部コピーを保持してもよい。モニタ論理１８は、イベントレコードを記憶するたびに、ヘッドポインタをＰＣＢにフラッシュする必要はない。その代わりに、しきい値またはバッファフルのイベントが発生するまで、あるいはコンテキスト切替のためにコンテキストを保存する必要があるときまで、フラッシュが遅延されてもよい。したがって、リングバッファをポーリングしているプロセスまたはスレッドが先への進捗を参照できるように、バッファしきい値を超えたときに、ヘッドポインタをメモリに強制的に移動させる必要がある。]
[0076] モニタ論理１８は、しきい値またはバッファフルの条件を検出しない限り、ソフトウェアに保持されているテイルポインタを読み出す必要はない。このような条件が発生した時点で、モニタ論理１８は、テイルポインタを再び読み出して、ソフトウェアがバッファから一部のレコードを削除したかどうかを確認するように構成されうる。レコードが削除されている場合、モニタ論理１８は、しきい値条件を再計算して、適宜処理する。このことは、バッファをポーリングするソフトウェアは、自身がしきい値イベントを検出した場合に、イベントレコードの処理を開始しなければならないことを暗に示している。ソフトウェアとの競合状態を回避するために、モニタ論理１８は、しきい値条件が真であると思われる間は、イベントレコードを記憶するたびにテイルポインタを再読込する必要がある。別の実施形態として、モニタ論理１８は、ｎ回（ｎは小さな数）ごとにテイルポインタを再読込みしてもよい。]
[0077] 各種実施形態では、命令のリタイア時に複数のイベントが発生しうる。例えば、メモリのポインタを介した間接的な分岐は、命令のリタイア、分岐のリタイアおよびＤＣａｃｈｅミスの各イベントを同時にトリガしうる。プロファイリングメカニズムは、命令に適用するすべてのイベントをカウントするが、１命令につき１つのイベントのみを報告するように構成されてもよい。他のイベントによって、イベントレコードが記憶されることはなくなる。どのイベントを報告するように選択するかは実装に依存し、同じプロセッサでも実行によって変わりうる。これにより、イベントのカウンタがいろいろなインターバルで切れるようになるため、定期的に複数のイベントを発生させる命令が、そのカテゴリのすべてにおいて報告されることが保証される。なお、別の実施形態では、複数のイベントが発生する場合、優先度方式を使用して、イベントの優先順位を決定してもよい。]
[0078] あるプロセスから別のプロセスに、あるいはカーネルからユーザプロセスに情報がリークされないことをＯＳは保証しなければならない点が留意される。このために、ＯＳがプロファイリングメカニズム２００をサポートしている場合、ＯＳは、コンテキスト切替の発生時にモニタ論理１８の状態が適切に設定されることを保証する必要があり、ハードウェアコンテキスト切替をサポートしているシステムでは、これが自動的に行われる必要がある。サポートしていない場合、各プロセスのＰＣＢポインタを、プロセスコンテキストの一部として保存および復元する必要がある。]
[0079] プロファイリングメカニズム２００の各種実装は、しきい値とオーバーフロー状態を迅速に検出するために、（サポートする最大同時発生イベント数まで）各種イベントのカウンタの現在の値を保持するための内部状態、イベントバッファへのポインタのコピー、およびテイルポインタのコピーを有する。一部の実施形態では、システムが揮発性のプロファイリング状態を維持する必要がある場合もある。ＯＳが、あるユーザスレッドから別のユーザスレッドにコンテキスト切替を行ったときに、古いユーザ状態をそのスレッドのコンテキストによって保存し、新しい状態をロードする必要がある。ハイパーバイザが、あるゲストＯＳから別のゲストＯＳへの切替を決定した場合、これをゲストシステムの状態にも行う必要がある。最後に、ＳＭＭコードがコアへの給電を停止することを決定しうるため、システムがＳＭＭに入るときとＳＭＭから出るときに、状態を記憶する必要がある。保存すべき状態の量は非常に少ない。例示的な実施形態では、ＰＣＢアドレスは８バイト、ＢｕｆｆｅｒＨｅａｄＯｆｆｓｅｔ値は４バイト、２６ビットカウンタ値はそれぞれ４バイトであり、ＭｉｓｓｅｄＥｖｅｎｔｓカウンタをインクリメントすべきことを示すフラグ（１ビット）である。残りのプロファイリング状態はすべて、ＰＣＢ自体から再構築することができる。]
[0080] ＳＭＭ保存領域は、揮発性のプロファイリング状態を含んでもよい。必要な場合、ＳＭＭの出入時にプロファイリング状態を保存および復元してもよい。プロセッサが電力状態を変更しようとするときに、状態を保存する必要があるが、プロファイリングはＣＰＬ３のみで実行されるため、他の場合にその状態を保存および復元する必要はない。]
[0081] 前述のように、ＰＣＢは、メモリに常時存在していなくてもよい。このため、モニタ論理１８は、ＯＳカーネル／ＶＭＭ／ＳＭＭにあるときは、ＰＣＢへのアクセスが失敗する可能性があるため、このようなアクセスを行ってはならない。プロファイリング状態の復元は、プロセッサがＣＰＬ３になってから行う必要があり、クラッシュせずにページフォルト例外を取得することができる。]
[0082] １つのノードが複数のプロセッサコアを有する実施形態について上で説明したが、Ｌ３キャッシュサブシステム２００，４００に関連する機能が、シングルコアプロセッサを含むどのようなタイプのプロセッサで使用されてもよいことが考察される。このような実施形態では、モニタ論理１８がそれぞれのコア内に存在してもよい。また、各種実施形態は、特定の実体をハードウェア実体またはソフトウェア実体として記述したが、上記の任意の実体が、必要に応じてハードウェア、ソフトウェアまたはその組み合わせで実装されてもよいことが考察される点も留意される。]
[0083] 上の実施形態についてかなり詳細に記載したが、上記の開示を完全に理解できれば、数多くの変形例および変更例が当業者にとって明らかであろう。下記の特許請求の範囲は、このような変形例および変更例を全て包含するものと解釈されることが意図される。]
[0084] 本発明は、一般にマイクロプロセッサに利用可能である。]

权利要求:

請求項1
１つ以上のプロセッサコア（１５Ａ，１５Ｂ）を有するプロセッサ（１２）であって、それぞれ１つ以上の実行スレッド（Ｔ１，Ｔ２，Ｔ３）を含む１つ以上のプロセス（Ｐ１，Ｐ２）を含む命令を実行するように構成された実行ロジックと、プロファイリングメカニズムとを備え、前記プロファイリングメカニズムは、前記１つ以上のプロセスをモニタし、モニタされている前記１つ以上のプロセスの制御のフローに割り込むことなく、前記１つ以上のプロセスに関連するパフォーマンスデータへのアクセスを提供するように構成されたモニタロジック（１８Ａ，１８Ｂ）と、前記パフォーマンスデータを収集するように構成されたモニタプロセス（モニタコード）とを有する、プロセッサ。
請求項2
前記モニタプロセスは、ユーザモードで動作中に、前記１つ以上のプロセッサコアによって実行可能なプログラム命令を含む、請求項１に記載のプロセッサ。
請求項3
前記モニタロジックは、モニタされている前記１つ以上のプロセスのそれぞれの個々のアドレス空間内に記憶バッファ領域（２３１，２３２）を作成するように更に構成されている、請求項１に記載のプロセッサ。
請求項4
前記モニタ論理は所定のイベントの発生を記録し、対応するイベントレコード（３０５，３１０，３２０）を前記記憶バッファ領域に書き込むように更に構成されている、請求項３に記載のプロセッサ。
請求項5
前記モニタプロセスは、モニタされている前記１つ以上のプロセスのそれぞれの個々のアドレス空間の各記憶バッファ領域が所定のしきい値まで一杯になったかどうかを判定するために、ポーリング命令を実行するように構成されている、請求項４に記載のプロセッサ。
請求項6
前記モニタロジックは、所定の記憶バッファ領域が所定のしきい値まで一杯になったと判定されると、前記モニタプロセスに通知するように構成されている、請求項５に記載のプロセッサ。
請求項7
前記モニタロジックは前記プロセッサコアの１つで実行中のオペレーティングシステムに割り込みを発生させるように更に構成されており、前記オペレーティングシステムは前記割り込みに応答してユーザプロセスに通知するように構成されており、前記ユーザプロセスは前記イベントレコードを検査し、前記イベントレコードに対応する１つ以上の所定のアクションを実行するように構成されている、請求項６に記載のプロセッサ。
請求項8
前記モニタロジックは前記プロセッサコアの１つで実行中のオペレーティングシステムに割り込みを発生させるように更に構成されており、前記オペレーティングシステムは前記割り込みに応答してユーザプロセスに通知するように構成されており、前記ユーザプロセスは前記イベントレコードを検査し、所定の記憶バッファから不揮発性ストレージに前記イベントレコードを転送するように構成されている、請求項６に記載のプロセッサ。
請求項9
前記モニタロジックは所定の記憶バッファ領域が所定のしきい値まで一杯になったと判定されると、前記プロセッサコアの１つで実行中のオペレーティングシステムに割り込みを発生させるように構成されており、前記オペレーティングシステムは前記割り込みに応答してユーザプロセスに通知し、前記ユーザプロセスは前記イベントレコードを検査し、所定の記憶バッファから不揮発性ストレージに前記イベントレコードを転送するように構成されている、請求項５に記載のプロセッサ。
請求項10
前記モニタプロセスは他のスレッドをモニタするように構成された１つのモニタスレッド（ユーザモードモニタコード）を含み、前記１つのモニタスレッドは前記モニタされているスレッドのそれぞれのイベントレコードを維持する、請求項１に記載のプロセッサ。